home *** CD-ROM | disk | FTP | other *** search
/ TeX 1995 July / TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO / tex-k / tex-k-archive.past / 1995.02 / 000107_swift@acs.bu.edu_Thu Feb 16 11:20:19 1995.msg < prev    next >
Internet Message Format  |  1995-02-28  |  5KB
  1. Received: from ACS3.BU.EDU by cs.umb.edu with SMTP id AA09903
  2.   (5.65c/IDA-1.4.4 for <tex-k@cs.umb.edu>); Thu, 16 Feb 1995 16:24:12 -0500
  3. Received: by acs3.bu.edu (8.6.9/BU_SmartClient-1.0)
  4.     id QAA270264; Thu, 16 Feb 1995 16:20:22 -0500
  5. From: swift@acs.bu.edu
  6. Message-Id: <199502162120.QAA270264@acs3.bu.edu>
  7. Date: Thu, 16 Feb 95 16:20:19 -0500
  8. Reply-To: swift@bu.edu
  9. To: bob@gnu.ai.mit.edu, tex-k@cs.umb.edu
  10. Subject: m68k-sony-newsos build 
  11. In-Reply-To: (Your message of Thu, 16 Feb 95 13:49:28 EST.)
  12.              <9502161849.AA27461@hill.gnu.ai.mit.edu> 
  13.  
  14.  
  15. I think Bob Chassell's last notice was very well put.  I would like to take one
  16. point he made, and reaffirm the arbitrariness in defining a 'vanilla' tex
  17. installation.
  18.  
  19. > I am not necessarily advocating one or many makefiles.  I am advocating a
  20. > top level makefile that enables you to build TeX from scratch.  It might also
  21. > let you build other things (or give you clear pointers on how to build
  22. > parts).  In a TeX distribution, I expect `make' to build what I need to
  23. > create .dvi files.
  24.  
  25. You define minimum funcationality as being able to "create .dvi files."  The
  26. single program TeX will allow you to create dvi files.  But it is very
  27. reasonable to say that one would like to be able to process the example files
  28. like simple.tex, discussed in the TeXbook, which requires the Plain TeX format,
  29. which requires additional library files.  A "non-expert" is likely to believe,
  30. quite reasonably, that if he can't process simple.tex, he can't "create dvi
  31. files."  To him, "TeX from scratch" includes the plain TeX format.  He probably
  32. doesn't want to know about the relationship between Tex the program and the
  33. Plain TeX format, and wants the installation to hide this from him.  Then
  34. again, maybe not, maybe he really just wants to build dvi files. 
  35.  
  36. But it doesn't stop there.  A .dvi file does most people no good unless more of
  37. the "friends" are around to present it to a human, which requires building
  38. fonts (unless you go for the primitive dvitype or dvi2tty) and a handful of
  39. auxiliary programs to manage them, and building a program to view or to print
  40. the dvi file.  Knuth's CMR fonts are standard.  Though these parts are not
  41. detailed in the TeXbook, it is assumed in the book that they are there,
  42. installed by an "expert".  This perhaps shows its datedness; anyway the TeXbook
  43. does not define a vanilla installation, we are on our own.
  44.  
  45. Yet other users and installers will be coming to TeX straight from LaTeX or
  46. LaTeX2e, and expect the latex format, the latex fonts, certain common packages,
  47. and so on to be there in a vanilla installation.  These people might reasonably
  48. not want to have to learn about the "internal" relationship between TeX and
  49. LaTeX.  They consider "TeX from scratch" to be able to process Lamport's or
  50. Shoepf's story.tex (or whatever the 2e little example is called).  And so on.
  51.  
  52. I venture it is impossible to anticipate what a non-expert expects and wants
  53. from a vanilla installation, both because they often don't know what they want,
  54. and different non-experts will want different things, each thinking that what
  55. they want is the perfectly obvious vanilla installation.
  56.  
  57. It is perhaps less misleading to acknowledge up front to a potential installer
  58. that this is not going to be as simple a process as with other pieces of
  59. softaware: the process will require learning enough details to figure out
  60. what is wanted.  No amount of user-friendliness and automation can
  61. anticipate this.  
  62.  
  63. I think tex's amorphousness distinguishes it from other large package-oriented
  64. software like GNU emacs, which despite its huge flexibility and number of
  65. library files still has a structure that places a single binary file in the
  66. center (spread across the autoloaded lisp files, I suppose) and all other
  67. programs as strictly subordinate and unnecessary for vanilla operation, which
  68. in the case of emacs is easier to define: load, maniputlate, and save text
  69. files from a terminal and/or X windows.  No fifty million kinds of output
  70. devices for example. 
  71.  
  72. Part of the question to be answered here is, until eventually the distribution
  73. is put into ideal form, to whom should the maintainers devote more of their
  74. finite time, the beginner or the person with some knowledge of tex installation
  75. structure?  
  76.  
  77. This difficulty only bears on one aspect of Bob's discussion, which otherwise
  78. as I say convinced me as sound thinking, e.g., the directory expectations
  79. during building.  These expectations, however, assume a source tar.gz file that
  80. is _entirely_ self-sufficent (the point of difficulty discussed above).  web2c
  81. isn't self-sufficent; many people want to use what it contains, and adapt it to
  82. an existing library structure.  If you don't have an existing library
  83. structure, or want to adopt the new standard one, you get one more tar.gz file,
  84. and plonk it in.  It does indeed require some knowledge on the part of the
  85. installer about what they want and need; but in my opinion as I said above,
  86. this is less misleading: I think a greater number of people will be more
  87. greatly confused by an installation that appears and installs like a "vanilla"
  88. installation, but turns out to be French Vanilla, that is, someone else's idea
  89. of vanilla that doesn't taste good.
  90.  
  91. regards, 
  92.  
  93. Matt
  94.  
  95.  
  96.  
  97.